Conversation
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
dinasaur404
force-pushed
the
dynamic-bindings
branch
from
edac725 to
fba9999
Compare
dinasaur404
force-pushed
the
dynamic-bindings
branch
2 times, most recently
from
dfb72f2 to
f668a5b
Compare
dinasaur404
force-pushed
the
dynamic-bindings
branch
from
f668a5b to
d932b65
Compare
a-robinson
left a comment
a-robinson
left a comment
There was a problem hiding this comment.
There's plenty still to figure out, but it feels very much like the right direction, the right goal to aim for.
| ```toml | ||
| name = "my-platform" | ||
|
|
||
| [[kv_namespaces]] |
There was a problem hiding this comment.
What's differentiating these configs as binding groups rather than just individual bindings? These look like the config for binding to just a single KV namespace / AI search namespace / R2 bucket.
|
|
||
| 1. Your customer writes a normal Worker that calls `env.KV.put("key", "value")`. | ||
| 2. On the platform side, you pass in the binding group scoped to the customer ID. | ||
| 3. When the customer's Worker calls `env.KV.put()` for the first time, the runtime sees "this is a write to binding group `CUSTOMER_KV`, scoped to `acme-corp`" — and if a KV store for `acme-corp` does not exist yet, it creates one. |
There was a problem hiding this comment.
How important is it that this gets created when the binding is first used vs when env.CUSTOMER_KV.get(customerId) is called in the dispatching worker?
Is it bad if the dispatching worker's call is what actually triggers creation of the resource?
| 1. Your customer writes a normal Worker that calls `env.KV.put("key", "value")`. | ||
| 2. On the platform side, you pass in the binding group scoped to the customer ID. | ||
| 3. When the customer's Worker calls `env.KV.put()` for the first time, the runtime sees "this is a write to binding group `CUSTOMER_KV`, scoped to `acme-corp`" — and if a KV store for `acme-corp` does not exist yet, it creates one. | ||
| 4. Each resource is created as a real, first-class resource with its own ID and data. |
There was a problem hiding this comment.
Is there anything special about how these resources will show up in the control plane APIs for each of the different resource types? e.g. will they be given special names, or tags, or some other field or organization that makes their binding group clear when you, for example, list KV namespaces?
|
|
||
| | Binding | What gets created | Creation trigger | | ||
| | ----------------------------------------------------------- | ----------------- | ---------------------------------------------------------------- | | ||
| | [KV](/kv/) | KV namespace | First write | |
There was a problem hiding this comment.
Is there a reason these lists are so specific about what provisions a resource?
Like, is it really intended that doing a get() would n't cause a KV namespace / R2 bucket / AI search index to be created?
| | [Queues](/queues/) | Queue | First `send()` | | ||
| | [Analytics Engine](/analytics/analytics-engine/) | Dataset | First write | | ||
| | [Rate Limiting](/workers/runtime-apis/bindings/rate-limit/) | Rate limiter | First `.limit()` call | | ||
| | [Workflows](/workflows/) | Workflow instance | First `.create()` call | |
There was a problem hiding this comment.
Workflows require a script to be defined in order to create an instance, and presumably different tenants will want their own scripts, won't they? Maybe the best option is to have the dispatcher create() the Workflow binding with a script for the tenant, something like env.WORKFLOW.create(customerId, {script: customerScript}).
IDK. Either way, this can probably better be sorted out elsewhere.
|
|
||
| Limits fall into two categories: | ||
|
|
||
| **Operation limits** count actions over the billing cycle. They reset at the start of each monthly billing period. |
There was a problem hiding this comment.
I shouldn't be making writing nits on docs that will surely be updated before publishing, but it'd be better to call out that these are examples, since as is I read it as the full list of each (which obviously isn't true).
| // DB, SEARCH, STORAGE still come from deploy-time config. | ||
| const userWorker = env.DISPATCHER.get(customerId, { | ||
| bindings: { | ||
| KV: env.CUSTOMER_KV.get(customerId), |
There was a problem hiding this comment.
It seems like during these migration cases, many customers would much rather get back an error than have a new resource automatically created for them when calling env.NS.get() if the resource doesn't already exist.
Because if they get back an error they can fall back to using the existing deploy-time binding. But if they deploy this kind of code before the namespace has been adopted/migrated, then they'll pass in an empty namespace to their tenant, to whom it will look like data was lost. And if that tenant then writes data into the new namespace, we'll have a split-brain scenario on our hands that will have to be manually resolved (by somehow merging the data from the real namespace and the automatically created empty namespace).
3 participants
Minor updates to Workers for Platforms configuration section.